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Abstract 


This document is a product of a joint Internet Engineering Task Force 
(IETF) / International Telecommunications Union Telecommunications 
Standardization Sector (ITU-T) effort to include an MPLS Transport 
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge 
(PWE3) architectures to support the capabilities and functionalities 
of a packet transport network as defined by the ITU-T. 


This document addresses the functionality described in the MPLS-TP 

Survivability Framework document (RFC 6372) and defines a protocol 

that may be used to fulfill the function of the Protection State 

Coordination for linear protection, as described in that document. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6378. 
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Introduction 


The MPLS Transport Profile (MPLS-TP) [RFC5921] is a framework for the 
construction and operation of packet-switched transport networks 
based on the architectures for MPLS ([RFC3031] and [RFC3032]) and for 
Pseudowires (PWs) ([RFC3985] and [RFC5659]) and the requirements of 
[RFC5654]. 


Network survivability is the ability of a network to recover traffic 
delivery following failure, or degradation, of network resources. 
The MPLS-TP Survivability Framework [RFC6372] is a framework for 
survivability in MPLS-TP networks, and describes recovery elements, 
types, methods, and topological considerations, focusing on 
mechanisms for recovering MPLS-TP Label Switched Paths (LSPs). 


Linear protection in mesh networks -- networks with arbitrary 
interconnectivity between nodes -- is described in Section 4.7 of 
[RFC6372]. Linear protection provides rapid and simple protection 
switching. In a mesh network, linear protection provides a very 
suitable protection mechanism because it can operate between any pair 
of points within the network. It can protect against a defect in an 
intermediate node, a span, a transport path segment, or an end-to-end 
transport path. 


1. Protection Architectures 


Protection switching is a fully allocated survivability mechanism. 

It is fully allocated in the sense that the route and resources of 
the protection path are reserved for a selected working path or set 
of working paths. It provides a fast and simple survivability 
mechanism that allows the network operator to easily grasp the active 
state of the network and that can operate between any pair of points 
within the network. 


As described in the Survivability Framework document [RFC6372], 
protection switching is applied to a protection domain. For the 
purposes of this document, we define the protection domain of a 
point-to-point LSP as consisting of two Label Edge Routers (LERs) and 
the transport paths that connect them (see Figure 3). For a point- 
to-multipoint LSP, the protection domain includes the root (or 
source) LER, the destination (or sink) LERs, and the transport paths 
that connect them. 


In 1+1 unidirectional architecture as presented in [RFC6372], a 
protection transport path is dedicated to the working transport path. 
Normal traffic is bridged (as defined in [RFC4427]) and fed to both 
the working and the protection paths by a permanent bridge at the 
source of the protection domain. The sink of the protection domain 
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uses a selector to choose either the working or protection path from 
which to receive the traffic, based on predetermined criteria, e.g., 
server defect indication. When used for bidirectional switching the 
1+1 protection architecture must also support a Protection State 
Coordination (PSC) protocol. This protocol is used to help 
coordinate between both ends of the protection domain in selecting 
the proper traffic flow. 


In the 1:1 architecture, a protection transport path is dedicated to 
the working transport path of a single service, and the traffic is 
only transmitted on either the working or the protection path, by 
using a selector at the source of the protection domain. A selector 
at the sink of the protection domain then selects the path that 
carries the normal traffic. Since the source and sink need to be 
coordinated to ensure that the selector at both ends select the same 
path, this architecture must support a PSC protocol. 


The 1:n protection architecture extends the 1:1 architecture above by 
sharing the protection path among n services. Again, the protection 
path is fully allocated and disjoint from any of the n working 
transport paths that it is being used to protect. The normal data 
traffic for each service is transmitted either on the normal working 
path for that service or, in cases that trigger protection switching 
(as listed in [RFC6372]), may be sent on the protection path. The 
switching action is similar to the 1:1 case where a selector is used 
at the source. In cases where multiple working path services have 
triggered protection switching, it should be noted that some 
services, dependent upon their Service Level Agreement (SLA), may not 
be transmitted as a result of limited resources on the protection 
path. In this architecture, there may be a need for coordination of 
the protection switching and for resource allocation negotiation. 

The procedures for this are for further study and may be addressed in 
future documents. 


1.2. Scope of the Document 


As was pointed out in the Survivability Framework [RFC6372] and 
highlighted above, there is a need for coordination between the end 
points of the protection domain when employing bidirectional 
protection schemes. This is especially true when there is a need to 
verify that the traffic continues to be transported on a 
bidirectional LSP that is co-routed. 


The scope of this document is to present a protocol for the 
Protection State Coordination of Linear Protection. The protocol 
addresses the protection of LSPs in an MPLS-TP network as required by 
[RFC5654] (in particular, requirements 63-65 and 74-79) and described 
in [RFC6372]. The basic protocol is designed for use in conjunction 
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with the 1:1 protection architecture, bidirectional protection, and 
for 1+1 protection of a bidirectional path (for both unidirectional 
and bidirectional protection switching). Applicability of the 
protocol for 1:1 unidirectional protection and for 1:n protection 
Schemes may be documented in a future document and is out of scope 
for this document. The applicability of this protocol to additional 
MPLS-TP constructs and topologies may be documented in future 
documents. 


While the unidirectional 1+1 protection architecture does not require 
the use of a coordination protocol, the protocol may be used by the 
ingress node of the path to notify the far-side end point that a 
Switching condition has occurred and verify the consistency of the 
end-point configuration. This use may be especially useful for 
point-to-multipoint transport paths, that are unidirectional by 
definition of [RFC5654]. The use of this protocol for point-to- 
multipoint paths is out of scope for this document and may be 
addressed in a future applicability document. 


2. Conventions Used in This Document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2.1. Acronyms 


This document uses the following acronyms: 


CT Channel Type 

DNR Do-not-Revert 

FS Forced Switch 

G-ACh Generic Associated Channel 

LER Label Edge Router 

LO Lockout of protection 

LSR Label Switching Router 

MEG Managed Entity Group 

MEP MEG End Point 

MPLS-TP Transport Profile for MPLS 

MS Manual Switch 

NR No Request 

OAM Operations, Administration, and Maintenance 
PSC Protection State Coordination Protocol 
S-PE Switching Provider Edge 

SD Signal Degrade 

SF Signal Fail 

SFc Clear Signal Fail 

SLA Service Level Agreement 
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T-PE Terminating Provider Edge 
WIR Wait-to-Restore 
2.2. Definitions and Terminology 


The terminology used in this document is based on the terminology 
defined in [RFC4427] and further adapted for MPLS-TP in [RFC6372]. 
In addition, we use the term "LER" to refer to an MPLS-TP Network 
Element, whether it is an LSR, LER, T-PE, or S-PE. 


3. Protection State Control Logic 


Protection switching processes the local triggers described in 
requirements 74-79 of [RFC5654] together with inputs received from 
the far-end LER. Based on these inputs, the LER will take certain 
protection switching actions, e.g., switching the selector to 
transmit on the working or protection path for 1:1 protection or 
switching the selector to receive the traffic for either 1:1 or 1+1 
protection and transmit different protocol messages. 


The following figure shows the logical decomposition of the 
Protection State Control logic into different logical processing 
units. These processing units are presented in subsequent 
subsections of this document. This logical decomposition is only 
intended for descriptive purposes; any implementation that produces 
the external behavior described in Section 4 is acceptable. 
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Server Indication Control-Plane Indication 


ta== SS S= PGS + Ho + 
| Local Request |«-------- | WIR | 
| logic | WTR Exps | Timer | 
$ O + Ho + 
| ^ 
Highest local|request 
V | Start/Stop 
4----------------- + | 
Remote PSC | PSC Control |------------ + 
=== +S===>5 > | logic | 
Request MEE xui CC + 
| Action di + 
FES=3S 333222335 = >| Message | 
Generator 
$ + 


Output PSC | Message 
V 


Figure 1: Protection State Control Logic 


Figure 1 describes the logical architecture of the protection 
Switching control. The Local Request logic unit accepts the triggers 
from the OAM, server layer, external operator commands, local control 
plane (when present), and the Wait-to-Restore timer. By considering 
all of these local request sources, it determines the highest 
priority local request. This high-priority request is passed to the 
PSC Control logic, that will cross-check this local request with the 
information received from the far-end LER. The PSC Control logic 
uses this input to determine what actions need to be taken, e.g., 
local actions at the LER, or what message should be sent to the far- 
end LER, and the current status of the protection domain. 
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Jes 


Local Request Logic 


The Local Request logic processes input triggers from five sources. 


o 


Operator command - the network operator may issue local 
administrative commands on the LER that trigger protection 
Switching. The commands Forced Switch, Manual Switch, Clear, 
Lockout of protection (defined in [RFC4427] as Forced switch-over, 
Manual switch-over, Clear, and Lockout of recovery LSP/span, 
respectively) MUST be supported. An implementation MAY provide 
additional commands for operator use; providing that these 
commands do not introduce incompatible behavior between two 
arbitrary implementations, they are outside the scope of this 
document. For example, an implementation could provide a command 
to manually set off a "WTR Expires" trigger (see below) input 
without waiting for the duration of the WTR timer; as this merely 
hastens the transition from one state to another and has no impact 
on the state machine itself, it would be perfectly valid. 


Server-layer alarm indication - the underlying server layer of the 
network detects failure conditions at the underlying layer and may 
issue an indication to the MPLS-TP layer. The server layer may 
employ its own protection switching mechanism; therefore, this 
input MAY be controlled by a hold-off timer that SHOULD be 
configurable by the network operator. The hold-off timer is 
described in greater detail in [RFC6372]. 


Control-Plane Indication - if there is a control plane active in 
the network (either signaling or routing), it MAY trigger 
protection switching based on conditions detected by the control 
plane. If the control plane is based on GMPLS [RFC3945], then the 
recovery process SHALL comply with the process described in 
[RFC4872] and [RFC4873]. 


OAM indication - OAM fault management or performance measurement 
tools may detect a failure or degrade condition on either the 
working or protection transport path, and this MUST input an 
indication to the Local Request logic. 


WTR Expires - The Wait-to-Restore timer is used in conjunction 
with recovery from failure conditions on the working path in 
revertive mode. The timer SHALL signal the PSC control process 
when it expires, and the end point SHALL revert to the normal 
transmission of the user data traffic. 


The input from these sources SHOULD be retained persistently for the 
duration of the condition that initiated the trigger. The Local 
Request logic processes these different input sources and, based on 
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the priorities between them (see Section 4.3.2), produces a current 
local request. If more than one local input source generates a 
trigger, then the Local Request logic selects the higher priority 
indicator and ignores any lower priority indicator. As a result, 
there is a single current local request that is passed to the PSC 
Control logic. The different local requests that may be output from 
the Local Request logic are as follows: 


o Clear - if the operator cancels an active local administrative 
command, i.e., LO/FS/MS. 


o Lockout of protection (LO) - if the operator requested to prevent 
switching data traffic to the protection path, for any purpose. 


o Signal Fail (SF) - if any of the server-layer, control-plane, or 
OAM indications signaled a failure condition on either the 
protection path or one of the working paths. 


o Signal Degrade (SD) - if any of the server-layer, control-plane, 
or OAM indications signaled a degraded transmission condition on 
either the protection path or one of the working paths. The 
determination and actions for SD are for further study and may 
appear in a separate document. All references to SD input are 
placeholders for this extension. 


o Clear Signal Fail (SFc) - if all of the server-layer, control- 
plane, or OAM indications are no longer indicating a failure 
condition on a path that was previously indicating a failure 
condition. 


o Forced Switch (FS) - if the operator requested that traffic be 
switched from one of the working paths to the protection path. 


o Manual Switch (MS) - if the operator requested that traffic be 
switched from the working path to the protection path. This is 
only relevant if there is no currently active fault condition or 
operator command. 


o WIR Expires (WTRExp) - generated by the WIR timer completing its 
period. 


If none of the input sources have generated any triggers, then the 


Local Request logic should generate a No Request (NR) as the current 
local request. 
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3.2. Remote Requests 


In addition to the local requests, generated as a result of the local 
triggers, indicated in the previous subsection, the PSC Control logic 
SHALL accept PSC messages from the far-end LER of the transport path. 
Remote messages indicate the status of the transport path from the 
viewpoint of the far-end LER. These messages may drive state changes 
on the local MEP, as defined later in this document. When using 1+1 
unidirectional protection, an LER that receives a remote request 
SHALL NOT perform any protection switching action, i.e., will 
continue to select traffic from the working path and transport 
traffic on both paths. 


The following remote requests may be received by the PSC process: 


o Remote LO - indicates that the remote end point is in Unavailable 
state due to a Lockout of protection operator command. 


o Remote SF - indicates that the remote end point has detected a 
Signal Fail condition on one of the transport paths in the 
protection domain. This remote message includes an indication of 
which transport path is affected by the SF condition. In 
addition, it should be noted that the SF condition may be either a 
unidirectional or a bidirectional failure, even if the transport 
path is bidirectional. 


o Remote SD - indicates that the remote end point has detected a 
Signal Degrade condition on one of the transport paths in the 
protection domain. This remote message includes an indication of 
which transport path is affected by the SD condition. In 
addition, it should be noted that the SD condition may be either a 
unidirectional or a bidirectional failure, even if the transport 
path is bidirectional. 


o Remote FS - indicates that the remote end point is operating under 
an operator command to switch the traffic to the protection path. 


o Remote MS - indicates that the remote end point is operating under 
an operator command to switch the traffic from the working path to 
the protection path. 


o Remote WIR - indicates that the remote end point has determined 


that the failure condition has recovered and has started its WIR 
timer in preparation for reverting to the Normal state. 
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o Remote DNR - indicates that the remote end point has determined 
that the failure condition has recovered and will continue 
transporting traffic on the protection path due to operator 
configuration that prevents automatic reversion to the Normal 
state. 


o Remote NR - indicates that the remote end point has no abnormal 
condition to report. 


3.3. PSC Control Logic 
The PSC Control logic accepts the following input: 


a. the current local request output from the Local Request logic 
(see Section 3.1), 


b. the remote request message from the remote end point of the 
transport path (see Section 3.2), and 


C. the current state of the PSC Control logic (maintained internally 
by the PSC Control logic). 


Based on the priorities between the different inputs, the PSC Control 
logic determines the new state of the PSC Control logic and what 
actions need to be taken. 


The new state information is retained by the PSC Control logic, while 
the requested action should be sent to the PSC Message Generator (see 
Section 3.4) to generate and transmit the proper PSC message to be 
transmitted to the remote end point of the protection domain. 


3.4. PSC Message Generator 


Based on the action output from the PSC Control logic, this unit 
formats the PSC protocol message that is transmitted to the remote 
end point of the protection domain. This message may either be the 
same as the previously transmitted message or change when the PSC 
control state (see Section 3.6) has changed. The messages are 
transmitted as described in Section 4.1 of this document. 


3.5. Wait-to-Restore (WTR) Timer 
The WIR timer is used to delay reversion to Normal state when 
recovering from a failure condition on the working path and the 


protection domain is configured for revertive behavior. The length 
of the timer may be provisioned by the operator. The WIR may be in 
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one of two states: Running or Stopped. The control of the WTR timer 
is managed by the PSC Control logic, by use of internal signals to 
start and stop, i.e., reset, the WIR timer. 


If the WIR timer expires prior to being stopped, it SHALL generate a 
WTR Expires local signal that is processed by the Local Request 
logic. If the WTR timer is running, sending a Stop command SHALL 
reset the timer, and put the WTR timer into Stopped state, but SHALL 
NOT generate a WTR Expires local signal. If the WTR timer is 
stopped, a Stop command SHALL be ignored. 


3.6. PSC Control States 


The PSC Control logic should maintain information on the current 
state of the protection domain. Information on the state of the 
domain is maintained by each LER within the protection domain. The 
state information would include information of the current state of 
the protection domain, an indication of the cause for the current 
state (e.g., unavailable due to local LO command, protecting due to 
remote FS), and, for each LER, should include an indication if the 
State is related to a remote or local condition. 


It should be noted that when referring to the "transport" of the data 
traffic, in the following descriptions and later in the document that 
the data will be transmitted on both the working and the protection 
paths when using 1+1 protection, and on either the working or the 
protection path exclusively when using 1:1 protection. When using 
1-1 protection, the receiving LER should select the proper 
transmission, according to the state of the protection domain. 


The protection domain states that are supported by the PSC Control 
logic are as follows: 


o Normal state - Both the protection and working paths are fully 
allocated and active, data traffic is being transported over (or 
selected from) the working path, and no trigger events are 
reported within the domain. 


o Unavailable state - The protection path is unavailable -- either 
as a result of an operator Lockout command or a failure condition 
detected on the protection path. 


o Protecting failure state - The working path has reported a 
failure/degrade condition and the user traffic is being 


transported (or selected) on the protection path. 


o Protecting administrative state - The operator has issued a 
command switching the user traffic to the protection path. 
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o Wait-to-Restore state - The protection domain is recovering from 
an SF/SD condition on the working path that is being controlled by 
the Wait-to-Restore (WTR) timer. 


o Do-not-Revert state - The protection domain has recovered from a 
Protecting state, but the operator has configured the protection 
domain not to automatically revert to the Normal state upon 
recovery. The protection domain SHALL remain in this state until 
the operator issues a command to revert to the Normal state or 
there is a new trigger to switch to a different state. 


See Section 4.3.3 for details on what actions are taken by the PSC 
Process logic for each state and the relevant input. 


3.6.1. Local and Remote State 


An end point may be in a given state as a result of either a local 
input indicator (e.g., OAM, WTR timer) or as a result of receiving a 
PSC message from the far-end LER. If the state is entered as a 
result of a local input indicator, then the state is considered a 
local state. If the state is entered as a result of a PSC message, 
in the absence of a local input, then the state is considered a 
remote state. This differentiation affects how the LER reacts to 
different inputs, as described in Section 4.3.3. The PSC Control 
logic should maintain, together with the current protection domain 
state, an indication of whether this is a local or remote state, for 
this LER. 


In any instance where the LER has both a local and remote indicator 
that cause the protection domain to enter a particular state, then 
the state is considered a local state, regardless of the order in 
which the indicators were processed. If, however, the LER has local 
and remote indicators that would cause the protection domain to enter 
different states, e.g., a local SF on working and a remote Lockout of 
protection message, then the input with the higher priority (see 
Section 4.3.2) will be the deciding factor and the source of that 
indicator will determine whether it is local or remote. In the given 
example, the result would be a Remote Unavailable state transmitting 
PSC messages that indicate an SF condition on the working path and 
that the protection path is not being used to transport protected 
traffic (as described in the next section). 


4. Protection State Coordination (PSC) Protocol 


Bidirectional protection switching, as well as unidirectional 1:1 
protection, requires coordination between the two end points in 
determining which of the two possible paths, the working or 
protection path, is transmitting the data traffic in any given 


Weingarten, et al. Standards Track [Page 14] 


RFC 6378 MPLS-TP LP October 2011 


situation. When protection switching is triggered as described in 
Section 3, the end points must inform each other of the switchover 
from one path to the other in a coordinated fashion. 


There are different possibilities for the type of coordinating 
protocol. One possibility is a two-phased coordination in which the 
LER that is initiating the protection switching sends a protocol 
message indicating the switch but the actual switchover is performed 
only after receiving an ”Ack' from the far-end LER. The other 
possibility is a single-phased coordination, in which the initiating 
LER performs the protection switchover to the alternate path and 
informs the far-end LER of the switch, and the far-end LER will 
complete the switchover. 


This protocol is a single-phased protocol, as described above. In 
the following subsections, we describe the protocol messages that are 
used between the two end points of the protection domain. 


4.1. Transmission and Acceptance of PSC Control Packets 


The PSC control packets SHALL be transmitted over the protection path 
only. This allows the transmission of the messages without affecting 
the normal data traffic in the most prevalent case, i.e., the Normal 
state. In addition, limiting the transmission to a single path 
avoids possible conflicts and race conditions that could develop if 
the PSC messages were sent on both paths. 


When the protection domain state is changed due to a local input, 
three PSC messages SHALL be transmitted as quickly as possible, to 
allow for rapid protection switching. This set of three rapid 
messages allows for fast protection switching even if one or two of 
these packets are lost or corrupted. When the protection domain 
state changes due to a remote message, the LER SHOULD send the three 
rapid messages. However, when the LER transfers from WTR state to 
Normal state as a result of a remote NR message, the three rapid 
messages SHALL be transmitted. After the transmission of the three 
rapid messages, the LER MUST retransmit the most recently transmitted 
PSC message on a continual basis. 


Both the default frequency of the three rapid messages as well as the 
default frequency of the continual message transmission SHALL be 
configurable by the operator. The actual frequencies used MAY be 
configurable, at the time of establishment, for each individual 
protected LSP. For management purposes, the operator SHOULD be able 
to retrieve the current default frequency values as well as the 
actual values for any specific LSP. For protection switching within 
50 ms, it is RECOMMENDED that the default interval of the first three 
rapid PSC messages SHOULD be no longer than 3.3 ms. Using this 
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frequency would allow the far-end to be guaranteed of receiving the 
trigger indication within 10 ms and completion of the switching 
operation within 50 ms. Subsequent messages SHOULD be continuously 
transmitted with a default interval of 5 seconds. The purpose of the 
continual messages is to verify that the PSC session is still alive. 


If no valid PSC message is received, over a period of several 
continual messages intervals, the last valid received message remains 
applicable. 


4.2. Protocol Format 


The protocol messages SHALL be sent over the G-ACh as described in 
[RFC5586]. There is a single channel type for the set of PSC 
messages. The actual message function SHALL be identified by the 
Request field of the ACH payload as described below. 


The channel type for the PSC messages SHALL be PSC-CT=0x0024. 
The following figure shows the format for the complete PSC message. 


0 1 2 3 
01:23 4-50" :8 9.QUI- 2 3-4 5 64 890: 31.23; 4.5 6 7 89.0 1 
E ————— — o o o + 
|0 0 0 1|Version| Reserved | PSC-CT 
tt tt tt 4-4-4 -F- —— — tt 
|Ver|Request |PT |R| Reserved1 | FPath | Path 
tt tt tt tn nn nt tt — 
| TLV Length | Reserved2 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- tt — 
7 Optional TLVs 
I nn +H 


: +— + — + — + 


+ 


Figure 2: Format of PSC Packet with a G-ACh Header 
Where: 


o Both Reservedl and Reserved2 fields MUST be set to 0 and ignored 
upon receipt. 


o The following subsections describe the remaining fields of the PSC 
payload. 


4.2.1. PSC Ver Field 


The Ver field identifies the version of the protocol. For this 
version of the document, the value SHALL be 1. 
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4.2.2. PSC Request Field 


The PSC protocol SHALL support transmission of the following requests 
between the two end points of the protection domain: 


o (14) Lockout of protection - indicates that the end point has 
disabled the protection path as a result of an administrative 
command. Both the FPath and Path fields SHALL be set to 0. 


o (12) Forced Switch - indicates that the transmitting end point has 
Switched traffic to the protection path as a result of an 
administrative command. The FPath field SHALL indicate that the 
working path is being blocked (i.e., FPath set to 1), and the Path 
field SHALL indicate that user data traffic is being transported 
on the protection path (i.e., Path set to 1). 


o (10) Signal Fail - indicates that the transmitting end point has 
identified a signal fail condition on either the working or 
protection path. The FPath field SHALL identify the path that is 
reporting the failure condition (i.e., if protection path, then 
FPath is set to 0; if working path, then FPath is set to 1), and 
the Path field SHALL indicate where the data traffic is being 
transported (i.e., if protection path is blocked, then Path is set 
to 0; if working path is blocked, then Path is set to 1). 


o (7) Signal Degrade - indicates that the transmitting end point has 
identified a degradation of the signal, or integrity of the packet 
transmission on either the working or protection path. This 
request is presented here only as a placeholder. The specifics 
for the method of identifying this degradation is out of scope for 
this document. The details of the actions to be taken for this 
Situation are left for future specification. 


o (5) Manual Switch - indicates that the transmitting end point has 
Switched traffic to the protection path as a result of an 
administrative Manual Switch command. The FPath field SHALL 
indicate that the working path is being blocked (i.e., FPath set 
to 1), and the Path field SHALL indicate that user data traffic is 
being transported on the protection path (i.e., Path set to 1). 


o (4) Wait-to-Restore - indicates that the transmitting end point is 
recovering from a failure condition of the working path and has 
started the Wait-to-Restore timer. FPath SHALL be set to 0 and 
ignored upon receipt. Path SHALL indicate the working path that 
is currently being protected (i.e., Path set to 1). 
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o (1) Do-not-Revert - indicates that the transmitting end point has 
recovered from a failure/blocked condition, but due to the local 
settings, is requesting that the protection domain continues to 
transport the data as if it is in a protecting state, rather than 
revert to the Normal state. FPath SHALL be set to 0 and ignored 
upon receipt. Path SHALL indicate the working path that is 
currently being protected (i.e., Path set to 1). 


o (0) No Request - indicates that the transmitting end point has 
nothing to report, FPath and Path fields SHALL be set according to 
the transmission state of the end point, see Section 4.3.3 for 
detailed scenarios. 


All other values are for future extensions (to be administered by 
IANA) and SHALL be ignored upon receipt. 


4.2.3. Protection Type (PT) Field 


The PT field indicates the currently configured protection 
architecture type, this SHOULD be validated to be consistent for both 
ends of the protection domain. If an inconsistency is detected, then 
an alarm SHALL be sent to the management system. The following are 
the possible values: 


o 3: bidirectional switching using a permanent bridge 

o 2: bidirectional switching using a selector bridge 

o 1: unidirectional switching using a permanent bridge 

o 0: for future extensions 

As described in the Introduction (Section 1.1) a 1+1 protection 

architecture is characterized by the use of a permanent bridge at the 

source node, whereas the 1:1 and 1:n protection architectures are 

characterized by the use of a selector bridge at the source node. 
4.2.4. Revertive (R) Field 

This field indicates that the transmitting end point is configured to 

work in revertive mode. If there is an inconsistency between the two 

end points, i.e., one end point is configured for revertive action 

and the second end point is in non-revertive mode, then the 


management system SHOULD be notified. The following are the possible 
values: 
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o 0 - non-revertive mode 
o 1 - revertive mode 

5. Fault Path (FPath) Field 


The FPath field indicates which path (i.e., working or protection) is 
identified to be in a fault condition or affected by an 
administrative command, when a fault or command is indicated by the 
Request field to be in effect. The following are the possible 
values: 


o 0: indicates that the anomaly condition is on the protection path 
o 1: indicates that the anomaly condition is on the working path 


o 2-255: for future extensions and SHALL be ignored by this version 
of the protocol. 


6. Data Path (Path) Field 


The Path field indicates which data is being transported on the 
protection path. Under normal conditions, the protection path 
(especially, in 1:1 or 1:n architecture) does not need to carry any 
user data traffic. If there is a failure/degrade condition on one of 
the working paths, then that working path's data traffic will be 
transported over the protection path. The following are the possible 
values: 


o 0: indicates that the protection path is not transporting user 
data traffic (in 1:n architecture) or transporting redundant user 
data traffic (in 1+1 architecture). 


o 1: indicates that the protection path is transmitting user traffic 
replacing the use of the working path. 


o 2-255: for future extensions and SHALL be ignored by this version 
of the protocol. 


7. Additional TLV Information 


It may be necessary for future applications of the protocol to 
include additional information for the proper processing of the 
requests. For this purpose, we provide for optional additional 
information to be included in the PSC payload. This information MUST 
include a header that indicates the total length (in bytes) of the 
additional information. 
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This information includes the following fields: 
o TLV Length: indicates the number of bytes included in the optional 
TLV information. For the basic PSC protocol operation described 


in this document, this value MUST be 0. 


o Optional TLVs: this includes any additional information formatted 


as TLV units. There are no TLV units defined for the basic PSC 
operation. 
4.3. Principles of Operation 


In all of the following subsections, assume a protection domain 
between LER-A and LER-Z, using paths W (working) and P (protection), 
as shown in Figure 3. 


Pes To NX perm * 

| LER-A | // Working Path \\ | LER-Z | 

NET IN | 
?« | >? 

| VINN Protection Path LEV | 

pescee + NM fl esse + 


Figure 3: Protection Domain 
4.3.1. Basic Operation 


The purpose of the PSC protocol is to allow an end point of the 
protection domain to notify its peer of the status of the domain that 
is known at the end point and coordinate the transmission of the data 
traffic. The current state of the end point is expressed in the 
values of the Request field (reflecting the local requests at that 
end point) and the FPath field (reflecting knowledge of a blocked 
path). The coordination between the end points is expressed by the 
value of the Path field (indicating where the user data traffic is 
being transmitted). Except during a protection switch, the value of 
the Path field should be identical for both end points at any 
particular time. The values of the Request and FPath fields may not 
be identical between the two end points. In particular it should be 
noted that a remote message may not cause the end point to change the 
Request field that is being transmitted while it does affect the Path 
field (see details in the following subsections). 
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The protocol is a single-phased protocol.  "Single-phased" implies 
that each end point notifies its peer of a change in the operation 
(switching to or from the protection path) and makes the switch 
without waiting for acknowledgement. As a side effect of using a 
single-phased protocol, there will be a short period during state 
transitions of one-sided triggers (e.g., operator commands or 
unidirectional SF) when one LER may be transporting/selecting the 
data from one transport path while the other end point is 
transporting/selecting from the other transport path. This should 
become coordinated once the remote message is received and the far- 
end LER performs the protection switching operation. 


The following subsections will identify the messages that will be 
transmitted by the end point in different scenarios. The messages 
are described as REQ(FP, P) -- where REQ is the value of the Request 
field, FP is the value of the FPath field, and P is the value of the 
Path field. All examples assume a protection domain between LER-A 
and LER-Z with a single working path and single protection path (as 
shown in Figure 3). Again, it should be noted that when using 1:1 
protection the data traffic will be transmitted exclusively on either 
the protection or working path; whereas when using 1+1 protection, 
the traffic will be transmitted on both paths and the receiving LER 
should select the appropriate signal based on the state. The text 
will refer to this transmission/selection as "transport" of the data 
traffic. For 1+1 unidirectional protection, the state of the 
selector will only be switched in reaction to a local message. When 
receiving a remote message, a LER that is configured for 1+1 
unidirectional protection, will transfer to the new remote state; 
however, it will continue to select data according to the latest 
known local state. When the LER transitions into the Normal state, 
the PSC Control Process SHALL check the persistent state of the local 
triggers to decide if it should further transition into a new state. 


4.3.2. Priority of Inputs 


As noted above (in Section 3.1), the PSC Control Process accepts 
input from five local input sources. There is a definition of 
priority between the different inputs that may be triggered locally. 
The list of local requests in order of priority are (from highest to 
lowest priority): 


l4 Clear (operator command) 
2. Lockout of protection (operator command) 
S. Forced Switch (operator command) 
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4. Signal Fail on protection (OAM / control-plane / server 
indication) 

Så Signal Fail on working (OAM / control-plane / server indication) 

6. Signal Degrade on working (OAM / control-plane / server 
indication) 

d Clear Signal Fail/Degrade (OAM / control-plane / server 
indication) 

8. Manual Switch (operator command) 

9. WTR Expires (WTR timer) 


10. No Request (default) 


As was noted above, the Local Request logic SHALL always select the 
local input indicator with the highest priority as the current local 
request, i.e., only the highest priority local input will be used to 
affect the control logic. All local inputs with lower priority than 
this current local request will be ignored. 


The remote message from the far-end LER is assigned a priority just 
below the similar local input. For example, a remote Forced Switch 
would have a priority just below a local Forced Switch but above a 
local Signal Fail on protection input. As mentioned in 

Section 3.6.1, the state transition is determined by the higher 
priority input between the highest priority local input and the 
remote message. This also determines the classification of the state 
as local or remote. The following subsections detail the transition 
based on the current state and the higher priority of these two 
inputs. 


4.3.3. Operation of PSC States 


The following subsections present the operation of the different 
states defined in Section 3.6. For each state, we define the 
reaction, i.e., the new state and the message to transmit, to each 
possible input -- either the highest priority local input or the PSC 
message from the remote LER. It should be noted that the new state 
of the protection domain is described from the point of view of the 
LER that is reporting the state; therefore, the language of "the LER 
goes into a state" is referring to the LER reporting that the 
protection domain is now in this new state. If the definition states 
to "ignore" the message, the intention is that the protection domain 
SHALL remain in its current state and the LER SHALL continue 
transmitting (as presented in Section 4.1) the current PSC message. 
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When a LER is in a remote state, i.e., state transition in reaction 
to a PSC message received from the far-end LER, and receives a new 
PSC message from the far-end LER that indicates a contradictory 
state, e.g., in remote Unavailable state receiving a remote FS(1,1) 
message, then the PSC Control logic SHALL reevaluate all inputs (both 
the local input and the remote message) as if the LER is in the 
Normal state. 


4.3.3.1. Normal State 


When the protection domain has no special condition in effect, the 
ingress LER SHALL forward the user data along the working path, and, 
in the case of 1+1 protection, the Permanent Bridge will bridge the 
data to the protection path as well. The receiving LER SHALL read 
the data from the working path. 


When the LER transitions into the Normal state, the PSC Control 
Process SHALL check the persistent state of the local triggers to 
decide if it should further transition into a new state. If the 
result of this check is a transition into a new state, the LER SHALL 
transmit the corresponding message described in this section and 
SHALL use the data path corresponding to the new state. When the 
protection domain remains in Normal state, the end point SHALL 
transmit an NR(0,0) message, indicating -- Nothing to report and data 
traffic is being transported on the working path. 


When the protection domain is in Normal state, the following 
transitions are relevant in reaction to a local input to the LER: 


o A local Lockout of protection input SHALL cause the LER to go into 
local Unavailable state and begin transmission of an LO(0,0) 
message. 


o A local Forced Switch input SHALL cause the LER to go into local 
Protecting administrative state and begin transmission of an 
FS(1,1) message. 


o A local Signal Fail indication on the protection path SHALL cause 
the LER to go into local Unavailable state and begin transmission 
of an SF(0,0) message. 


o A local Signal Fail indication on the working path SHALL cause the 
LER to go into local Protecting failure state and begin 
transmission of an SF(1,1) message. 


o A local Manual Switch input SHALL cause the LER to go into local 


Protecting administrative state and begin transmission of an 
MS (1,1) message. 
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o All other local inputs SHALL be ignored. 


In Normal state, remote messages would cause the following reaction 
from the LER: 


o A remote Lockout of protection message SHALL cause the LER to go 
into remote Unavailable state, while continuing to transmit the 
NR(0,0) message. 


o A remote Forced Switch message SHALL cause the LER to go into 
remote Protecting administrative state and begin transmitting an 
NR(0,1) message. 


o A remote Signal Fail message that indicates that the failure is on 
the protection path SHALL cause the LER (LER-A) to go into remote 
Unavailable state, while continuing to transmit the NR(0,0) 
message. 


o A remote Signal Fail message that indicates that the failure is on 
the working path SHALL cause the LER to go into remote Protecting 
failure state, and transmit an NR(0,1) message. 


o A remote Manual Switch message SHALL cause the LER to go into 
remote Protecting administrative state, and transmit an NR(0,1) 
message. 


o All other remote messages SHALL be ignored. 
4.3.3.2. Unavailable State 


When the protection path is unavailable -- either as a result of a 
Lockout operator command, or as a result of a SF detected on the 
protection path -- then the protection domain is in the Unavailable 
state. In this state, the data traffic SHALL be transported on the 
working path and is not protected. When the domain is in Unavailable 
state, the PSC messages may not get through: therefore, the 
protection is more dependent on the local inputs than the remote 
messages (that may not be received). 


The protection domain will exit the Unavailable state and revert to 
the Normal state when either the operator clears the Lockout command 
or the protection path recovers from the signal fail or degraded 
Situation. Both ends will continue to send the PSC messages over the 
protection path, as a result of this recovery. 


When the LER (assume LER-A) is in Unavailable state, the following 
transitions are relevant in reaction to a local input: 
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o 


A local Clear input SHALL be ignored if the LER is in remote 
Unavailable state. If in local Unavailable state due to a Lockout 
command, then the input SHALL cause the LER to go to Normal state. 


A local Lockout of protection input SHALL cause the LER to remain 
in local Unavailable state and transmit an LO(0,0) message to the 
far-end LER (LER-Z). 


A local Clear SF of the protection path in local Unavailable state 
that is due to an SF on the protection path SHALL cause the LER to 
go to Normal state. If the LER is in remote Unavailable state but 
has an active local SF condition, then the local Clear SF SHALL 
clear the SF local condition and the LER SHALL remain in remote 
Unavailable state and begin transmitting NR(0,0) messages. In all 
other cases, the local Clear SF SHALL be ignored. 


A local Forced Switch SHALL be ignored by the PSC Control logic 
when in Unavailable state as a result of a (local or remote) 
Lockout of protection. If in Unavailable state due to an SF on 
protection, then the FS SHALL cause the LER to go into local 
Protecting administrative state and begin transmitting an FS(1,1) 
message. It should be noted that due to the unavailability of the 
protection path (i.e., due to the SF condition) that this FS may 
not be received by the far-end until the SF condition is cleared. 


A local Signal Fail on the protection path input when in local 
Unavailable state (by implication, this is due to a local SF on 
protection) SHALL cause the LER to remain in local Unavailable 
state and transmit an SF(0,0) message. 


A local Signal Fail on the working path input when in remote 
Unavailable state SHALL cause the LER to remain in remote 


Unavailable state and transmit an SF(1,0) message. 


All other local inputs SHALL be ignored. 


If remote messages are being received over the protection path, then 
they would have the following effect: 


o 


A remote Lockout of protection message SHALL cause the LER to 
remain in Unavailable state (note that if the LER was previously 
in local Unavailable state due to a Signal Fail on the protection 
path, then it will now be in remote Unavailable state) and 
continue transmission of the current message (either NR(0,0) or 
LO(0,0) or SF(0,0)). 
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o A remote Forced Switch message SHALL be ignored by the PSC Control 
logic when in Unavailable state as a result of a (local or remote) 
Lockout of protection. If in Unavailable state due to a local or 
remote SF on protection, then the FS SHALL cause the LER to go 
into remote Protecting administrative state; if in Unavailable 
state due to local SF, begin transmitting an SF(0,1) message. 


o A remote Signal Fail message that indicates that the failure is on 
the protection path SHALL cause the LER to remain in Unavailable 
state and continue transmission of the current message (either 
NR(0,0) or SF(0,0) or LO(0,0)). 


o A remote No Request, when the LER is in remote Unavailable state 
and there is no active local Signal Fail SHALL cause the LER to go 
into Normal state and continue transmission of the current 
message. If there is a local Signal Fail on the protection path, 
the LER SHALL remain in local Unavailable state and transmit an 
SF(0,0) message. If there is a local Signal Fail on the working 
path, the LER SHALL go into local Protecting Failure state and 
transmit an SF(1,1) message. When in local Unavailable state, the 
remote message SHALL be ignored. 


o All other remote messages SHALL be ignored. 


4.3.3.3. Protecting Administrative State 


In the Protecting administrative state, the user data traffic SHALL 
be transported on the protection path, while the working path is 
blocked due to an operator command, i.e., Forced Switch or Manual 
Switch. The difference between a local FS and local MS affects what 


local indicators may be received -- the Local Request logic will 
block any local SF when under the influence of a local FS, whereas 
the SF would override a local MS. In general, an MS will be canceled 


in case of either a local or remote SF or LO condition. 
The following describe the reaction to local input: 


o A local Clear SHALL be ignored if in remote Protecting 


administrative state. If in local Protecting administrative 
state, then this input SHALL cause the LER to go into Normal 
state. 


o A local Lockout of protection input SHALL cause the LER to go into 
local Unavailable state and begin transmission of an LO(0,0) 
message. 


o A local Forced Switch input SHALL cause the LER to remain in local 
Protecting administrative state and transmit an FS(1,1) message. 
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o A local Signal Fail indication on the protection path SHALL cause 
the LER to go into local Unavailable state and begin transmission 
of an SF(0,0) message, if the current state is due to a (local or 
remote) Manual Switch operator command. If the LER is in (local 
or remote) Protecting administrative state due to an FS situation, 
then the SF on protection SHALL be ignored. 


o A local Signal Fail indication on the working path SHALL cause the 
LER to go into local Protecting failure state and begin 
transmitting an SF(1,1) message, if the current state is due to a 
(local or remote) Manual Switch operator command. If the LER is 
in remote Protecting administrative state due to a remote Forced 
Switch command, then this local indication SHALL cause the LER to 
remain in remote Protecting administrative state and transmit an 
SF(1,1) message. If the LER is in local Protecting administrative 
state due to a local Forced Switch command, then this indication 
SHALL be ignored (i.e., the indication should have been blocked by 
the Local Request logic). 


o A local Clear SF SHALL clear any local SF condition that may 
exist. If in remote Protecting administrative state, the LER 
SHALL stop transmitting the SF(x,1) message and begin transmitting 
an NR(0,1) message. 


o A local Manual Switch input SHALL be ignored if in remote 
Protecting administrative state due to a remote Forced Switch 
command. If the current state is due to a (local or remote) 
Manual Switch operator command, it SHALL cause the LER to remain 
in local Protecting administrative state and transmit an MS(1,1) 
message. 


o All other local inputs SHALL be ignored. 


While in Protecting administrative state the LER may receive and 
react as follows to remote PSC messages: 


o A remote Lockout of protection message SHALL cause the LER to go 
into remote Unavailable state and begin transmitting an NR(0,0) 
message. It should be noted that this automatically cancels the 
current Forced Switch or Manual Switch command and data traffic is 
reverted to the working path. 


o A remote Forced Switch message SHALL be ignored by the PSC Process 
logic if there is an active local Forced Switch operator command. 
If the Protecting administrative state is due to a remote Forced 
Switch message, then the LER SHALL remain in remote Protecting 
administrative state and continue transmitting the last message. 
If the Protecting administrative state is due to either a local or 
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o 


remote Manual Switch, then the LER SHALL remain in remote 
Protecting administrative state (updating the state information 
with the proper relevant information) and begin transmitting an 
NR(0,1) message. 


A remote Signal Fail message indicating a failure on the 
protection path SHALL cause the LER to go into remote Unavailable 
state and begin transmitting an NR(0,0) message, if the Protecting 
administrative state is due to a Manual Switch command. It should 
be noted that this automatically cancels the current Manual Switch 
command and data traffic is reverted to the working path. 


A remote Signal Fail message indicating a failure on the working 
path SHALL be ignored if there is an active local Forced Switch 
command. If the Protecting state is due to a local or remote 
Manual Switch, then the LER SHALL go to remote Protecting failure 
state and begin transmitting an NR(0,1) message. 


A remote Manual Switch message SHALL be ignored by the PSC Control 
logic if in Protecting administrative state due to a local or 
remote Forced Switch. If in Protecting administrative state due 
to a remote Manual Switch, then the LER SHALL remain in remote 
Protecting administrative state and continue transmitting the 
current message. If in local Protecting administrative state due 
to an active Manual Switch, then the LER SHALL remain in local 
Protecting administrative state and continue transmission of the 
MS(1,1) message. 


A remote DNR(0,1) message SHALL be ignored if in local Protecting 
administrative state. If in remote Protecting administrative 
state, then the LER SHALL go to Do-not-Revert state and continue 
transmitting the current message. 


A remote NR(0,0) message SHALL be ignored if in local Protecting 
administrative state. If in remote Protecting administrative 
state and there is no active local Signal Fail indication, then 
the LER SHALL go to Normal state and begin transmitting an NR(0,0) 
message. If there is a local Signal Fail on the working path, the 
LER SHALL go to local Protecting failure state and begin 
transmitting an SF(1,1) message. 


All other remote messages SHALL be ignored. 


4.3.3.4. Protecting Failure State 


When the protection mechanism has been triggered and the protection 
domain has performed a protection switch, the domain is in the 
Protecting failure state. In this state, the normal data traffic 
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SHALL be transported on the protection path. When an LER is in this 
state, it implies that there either was a local SF condition or it 
received a remote SF PSC message. The SF condition or message 
indicated that the failure is on the working path. 


This state may be overridden by the Unavailable state triggers, i.e., 
Lockout of protection or SF on the protection path, or by issuing an 
FS operator command. This state will be cleared when the SF 
condition is cleared. In order to prevent flapping due to an 
intermittent fault, the LER SHOULD employ a Wait-to-Restore timer to 
delay return to Normal state until the network has stabilized (see 
Section 3.5). 


The following describe the reaction to local input: 


o A local Clear SF SHALL be ignored if in remote Protecting failure 
state. If in local Protecting failure state and the LER is 
configured for revertive behavior, then this input SHALL cause the 
LER to go into Wait-to-Restore state, start the WTR timer, and 
begin transmitting a WTR(0,1) message. If in local Protecting 
failure state and the LER is configured for non-revertive 
behavior, then this input SHALL cause the LER to go into Do-not- 
Revert state and begin transmitting a DNR(0,1) message. 


o A local Lockout of protection input SHALL cause the LER to go into 
Unavailable state and begin transmission of an LO(0,0) message. 


o A local Forced Switch input SHALL cause the LER to go into 
Protecting administrative state and begin transmission of an 
FS(1,1) message. 


o A local Signal Fail indication on the protection path SHALL cause 
the LER to go into Unavailable state and begin transmission of an 
SF(0,0) message. 


o A local Signal Fail indication on the working path SHALL cause the 
LER to remain in local Protecting failure state and transmit an 
sr (1,1) message. 

o All other local inputs SHALL be ignored. 


While in Protecting failure state, the LER may receive and react as 
follows to remote PSC messages: 


o A remote Lockout of protection message SHALL cause the LER to go 


into remote Unavailable state, and if in local Protecting failure 
state, then the LER SHALL transmit an SF (1,0) message; otherwise, 
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it SHALL transmit an NR(0,0) message. It should be noted that 
this may cause loss of user data since the working path is still 
in a failure condition. 


o A remote Forced Switch message SHALL cause the LER go into remote 
Protecting administrative state, and if in local Protecting 
failure state, the LER SHALL transmit the SF (1,1) message; 
otherwise, it SHALL transmit NR(0,1). 


o A remote Signal Fail message indicating a failure on the 
protection path SHALL cause the LER to go into remote Unavailable 
state, and if in local Protecting failure state, then the LER 
SHALL transmit an SF (1,0) message; otherwise, it SHALL transmit an 
NR(0,0) message. It should be noted that this may cause loss of 
user data since the working path is still in a failure condition. 


o If in remote Protecting failure state, a remote Wait-to-Restore 
message SHALL cause the LER to go into remote Wait-to-Restore 
state and continue transmission of the current message. 


o If in remote Protecting failure state, a remote Do-not-Revert 
message SHALL cause the LER to go into remote Do-not-Revert state 
and continue transmission of the current message. 


o If in remote Protecting failure state, a remote NR(0,0) SHALL 
Cause the LER to go to Normal state. 


o All other remote messages SHALL be ignored. 
4.3.3.5. Wait-to-Restore State 


When recovering from a failure condition on the working path, the 
Wait-to-Restore state is used by the PSC protocol to delay reverting 
to the Normal state, for the period of the WTR timer to allow the 
recovering failure to stabilize. While in the Wait-to-Restore state, 
the data traffic SHALL continue to be transported on the protection 
path. The natural transition from the Wait-to-Restore state to 
Normal state will occur when the WTR timer expires. 


When in Wait-to-Restore state, the following describe the reaction to 
local inputs: 


o A local Lockout of protection command SHALL send the Stop command 


to the WTR timer, go into local Unavailable state, and begin 
transmitting an LO(0,0) message. 
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o 


o 


A local Forced Switch command SHALL send the Stop command to the 
WTR timer, go into local Protecting administrative state, and 
begin transmission of an FS(1,1) message. 


A local Signal Fail indication on the protection path SHALL send 
the Stop command to the WTR timer, go into local Unavailable 
state, and begin transmission of an SF(0,0) message. 


A local Signal Fail indication on the working path SHALL send the 
Stop command to the WTR timer, go into local Protecting failure 
state, and begin transmission of an SF(1,1) message. 


A local Manual Switch input SHALL send the Stop command to the WTR 
timer, go into local Protecting administrative state, and begin 


transmission of an MS(1,1) message. 


A local WTR Expires input SHALL cause the LER to remain in Wait- 
to-Restore state, and begin transmitting an NR(0,1) message. 


All other local inputs SHALL be ignored. 


When in Wait-to-Restore state, the following describe the reaction to 
remote messages: 


o 


A remote Lockout of protection message SHALL send the Stop command 
to the WTR timer, go into remote Unavailable state, and begin 
transmitting an NR(0,0) message. 


A remote Forced Switch message SHALL send the Stop command to the 
WTR timer, go into remote Protecting administrative state, and 
begin transmission of an NR(0,1) message. 


A remote Signal Fail message for the protection path SHALL send 
the Stop command to the WTR timer, go into remote Unavailable 
State, and begin transmission of an NR(0,0) message. 


A remote Signal Fail message for the working path SHALL send the 
Stop command to the WTR timer, go into remote Protecting failure 
state, and begin transmission of an NR(0,1) message. 


A remote Manual Switch message SHALL send the Stop command to the 
WTR timer, go into remote Protecting administrative state, and 
begin transmission of an NR(0,1) message. 


If the WTR timer is running, then a remote NR message SHALL be 
ignored. If the WTR timer is stopped, then a remote NR message 
SHALL cause the LER to go into Normal state. 
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o All other remote messages SHALL be ignored. 
4.3.3.6.  Do-not-Revert State 


Do-not-Revert state is a continuation of the Protecting failure state 
when the protection domain is configured for non-revertive behavior. 
While in Do-not-Revert state, data traffic SHALL continue to be 
transported on the protection path until the administrator sends a 
command to revert to Normal state. It should be noted that there is 
a fundamental difference between this state and Normal -- whereas 
Forced Switch in Normal state actually causes a switch in the 
transport path used, in Do-not-Revert state, the Forced Switch just 
switches the state (to Protecting administrative state) but the 
traffic would continue to be transported on the protection path! To 
revert back to Normal state, the administrator SHALL issue a Lockout 
of protection command followed by a Clear command. 


When in Do-not-Revert state, the following describe the reaction to 
local input: 


o A local Lockout of protection command SHALL cause the LER to go 
into local Unavailable state and begin transmitting an LO(0,0) 
message. 


o A local Forced Switch command SHALL cause the LER to go into local 
Protecting administrative state and begin transmission of an 
FS(1,1) message. 


o A local Signal Fail indication on the protection path SHALL cause 
the LER to go into local Unavailable state and begin transmission 
of an SF(0,0) message. 


o A local Signal Fail indication on the working path SHALL cause the 
LER to go into local Protecting failure state and begin 
transmission of an SF(1,1) message. 


o A local Manual Switch input SHALL cause the LER to go into local 
Protecting administrative state and begin transmission of an 
MS (1,1) message. 

o All other local inputs SHALL be ignored. 


When in Do-not-Revert state, the following describe the reaction to 
remote messages: 


o A remote Lockout of protection message SHALL cause the LER to go 


into remote Unavailable state and begin transmitting an NR(0,0) 
message. 
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o A remote Forced Switch message SHALL cause the LER to go into 
remote Protecting administrative state and begin transmission of 
an NR(0,1) message. 


o A remote Signal Fail message for the protection path SHALL cause 
the LER to go into remote Unavailable state and begin transmission 
of an NR(0,0) message. 


o A remote Signal Fail message for the working path SHALL cause the 
LER to go into remote Protecting failure state and begin 
transmission of an NR(0,1) message. 

o A remote Manual Switch message SHALL cause the LER to go into 
remote Protecting administrative state and begin transmission of 
an NR(0,1) message. 

o All other remote messages SHALL be ignored. 

5. IANA Considerations 


5.1. Pseudowire Associated Channel Type 


In the "Pseudowire Name Spaces (PWE3)" registry, IANA maintains the 
"Pseudowire Associated Channel Types" registry. 


IANA has assigned a new code point from this registry. The code 
point has been assigned from the code point space that requires "IETF 
Review" as follows: 


Registry: 
Value Description TLV Follows Reference 
0x0024 Protection State no [this document] 


Coordination Protocol - 
Channel Type (PSC-CT) 


5.2. PSC Request Field 
IANA has created and maintains a new sub-registry within the 


"Multiprotocol Label Switching (MPLS) Operations, Administration, and 
Management (OAM) Parameters" registry called the "MPLS PSC Request 


Registry". All code points within this registry shall be allocated 
according to the "Standards Action" procedure as specified in 
[RFC5226]. 


The PSC Request Field is 4 bits, and the values have been allocated 
as follows: 
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Value Description Reference 
0 No Request [this document] 
1 Do-not-Revert [this document] 
2 - 3 Unassigned 
4 Wait-to-Restore [this document] 
5 Manual Switch [this document] 
6 Unassigned 
7 Signal Degrade [this document] 
8 - 9 Unassigned 
10 Signal Fail [this document] 
11 Unassigned 
12 Forced Switch [this document] 


13 Unassigned 
14 Lockout of protection [this document] 
15 Unassigned 


5.3. Additional TLVs 


The IANA has created and maintains a new sub-registry within the 
"Multiprotocol Label Switching (MPLS) Operations, Administration, and 
Management (OAM) Parameters" registry called the "MPLS PSC TLV 
Registry". All code points within this registry shall be allocated 
according to the "IETF Review" procedure as specified in [RFC5226]. 


6. Security Considerations 


MPLS-TP is a subset of MPLS and so builds upon many of the aspects of 
the security model of MPLS. MPLS networks make the assumption that 
it is very hard to inject traffic into a network and equally hard to 
cause traffic to be directed outside the network. The control-plane 
protocols utilize hop-by-hop security and assume a "chain-of-trust" 
model such that end-to-end control-plane security is not used. For 
more information on the generic aspects of MPLS security, see 
[RFC5920]. 


This document describes a protocol carried in the G-ACh [RFC5586], 
and so is dependent on the security of the G-ACh, itself. The G-ACh 
is a generalization of the Associated Channel defined in [RFC4385]. 
Thus, this document relies heavily on the security mechanisms 
provided for the Associated Channel and described in those two 
documents. 


A specific concern for the G-ACh is that is can be used to provide a 
covert channel. This problem is wider than the scope of this 
document and does not need to be addressed here, but it should be 
noted that the channel provides end-to-end connectivity and SHOULD 
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NOT be policed by transit nodes. Thus, there is no simple way of 
preventing any traffic being carried between in the G-ACh consenting 
nodes. 


A good discussion of the data-plane security of an associated channel 
may be found in [RFC5085]. That document also describes some 
mitigation techniques. 


It should be noted that the G-ACh is essentially connection oriented 
So injection or modification of control messages specified in this 
document require the subversion of a transit node. Such subversion 
is generally considered hard in MPLS networks and impossible to 
protect against at the protocol level. Management level techniques 
are more appropriate. 


However, a new concern for this document is the accidental corruption 
of messages (through faulty implementations or random corruption). 
The main concern is around the Request, FPath, and Path fields as a 
change to these fields would change the behavior of the peer end 
point. Although this document does not define a way to avoid a 
change in network behavior upon receipt of a message indicating a 
change in protection status, the transition between states will 
converge on a known and stable behavior in the face of messages that 
do not match reality. 
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Appendix A. PSC State Machine Tables 


The PSC state machine is described in Section 4.3.3. This appendix 
provides the same information but in tabular format. In the event of 
a mismatch between these tables and the text in Section 4.3.3, the 
text is authoritative. Note that this appendix is intended to be a 
functional description, not an implementation specification. 


For the sake of clarity of the table, the six states listed in the 
text are split into 13 states. The logic of the split is to 
differentiate between the different cases given in the conditional 
statements in the descriptions of each state in the text. In 
addition, the remote and local states were split for the Unavailable, 
Protecting failure, and Protecting administrative states. 


There is only one table for the PSC state machine, but it is broken 
into two parts for space reasons. The first part lists the 13 
possible states, the eight possible local inputs (that is, inputs 
that are generated by the node in question), and the action taken 
when a given input is received when the node is in a particular 
state. The second part of the table lists the 13 possible states and 
the eight remote inputs (inputs that come from a node other than the 
one executing the state machine). 


There are 13 rows in the table, headers notwithstanding. These rows 
are the 13 possible extended states in the state machine. 


The text in the first column is the current state. Those states that 
have both source and cause are formatted as State:Cause:Source. For 
example, the string UA:LO:L indicates that the current state is 
‘Unavailable’, that the cause of the current state is a Lockout of 


protection that was a local input. In contrast, the state N simply 
is Normal; there is no need to track the cause for entry into Normal 
state. 
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The 13 extended states, 


N 
UA:LO:L 
UA:P:L 
UA:LO:R 
UA:P 
PF:W:L 
PF:W 


PA:F:L 


PA:M:L 


MPLS- 


Normal state 

Unavailable state due to 
Unavailable state due to 
Unavailable state due to 
Unavailable state due to 


Protecting 
Protecting 
path 
Protecting 
command 
Protecting 
command 
Protecting 
Protecting 


failure state 
failure state 


TP LP 


October 2011 


as they appear in the table, are as follows: 


local Lockout 
local SF on protection path 


remote 
remote 
due to 
due to 


administrative state 


administrative state 


Lockout of protection message 
SF message on protection path 
local SF on working path 

remote SF message on working 


due to local FS operator 


due to local MS operator 


administrative state 
administrative state 
Wait-to-Restore state 
Do-not-Revert state 


due to remote FS message 
due to remote MS message 


Each state corresponds to the transmission of a particular set of 
Path bits. The table below lists the message that 
is generally sent in each particular state. If the message to be 
sent in a particular state deviates from the table below, it is noted 
in the footnotes to the state-machine table. 
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The top row in each table is the list of possible inputs. The local 
inputs are as follows: 


NR No Request 
OC Operator Clear 
LO Lockout of protection 


SF-P Signal Fail on protection path 
SF-W Signal Fail on working path 


FS Forced Switch 
SFc Clear Signal Fail 
MS Manual Switch 


WTRExp WTR Expired 
and the remote inputs are as follows: 


LO remote LO message 

SF-P remote SF message indicating protection path 
SF-W remote SF message indicating working path 

FS remote FS message 

MS remote MS message 

WIR remote WIR message 

DNR remote DNR message 

NR remote NR message 


Section 4.3.3 refers to some states as 'remote” and some as 'local'. 
By definition, all states listed in the table of local sources are 
local states, and all states listed in the table of remote sources 
are remote states. For example, Section 4.3.3.1 says "A local 
Lockout of protection input SHALL cause the LER to go into local 
Unavailable state". As the trigger for this state change is a local 
one, ”local Unavailable state’ is, by definition, displayed in the 
table of local sources. Similarly, Section 4.3.3.1 also states that 


"A remote Lockout of protection message SHALL cause the LER to go 
into remote Unavailable state" means that the state represented in 
the Unavailable rows in the table of remote sources is by definition 
a remote Unavailable state. 


Each cell in the table below contains either a state, a footnote, or 
the letter 'i'. 'i' stands for Ignore, and is an indication to 
continue with the current behavior. See Section 4.3.3. The 
footnotes are listed below the table. 
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Part 1: Local input state machine 
| oc | 16 | sF-P | FS | SF-w | sFc | 

-------- 4R-----4-------4------4------4------p------4- 
N | i |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |P 
UA:LO:L | N | i | i [rd | i paz 
UA:P:L | i — |UA:LO:L| i [PA:F:L| i VERSTE | 
UA:LO:R | i [UA:LO:L| [1] | i Sr» MEST "| 
UA:P:R i UA:LO:L Hr o [3] [6] 
PF:W:L | i bans dr PA:F:L| i [7] 
PF:W:R | i |UA:LO:L/UA:P:L|/PA:F:L|PF:W:L| i | 
PA:F:L | N — [UA:LO:L| i | i EE | i | 
PA:M:L | N  |UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i | 
PA:F:R | i |UA:LO:L] i [PA:F:L| [4] | [8] | 
PA:M:R | i — [UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i |P 
WTR i UA:LO:L|UA:P:L|PA:F:L|PF:W:L| i P 
DNR | i bees MIL i E 

Part 2: Remote messages state machine 

| Lo | SF-P | FS | SF-w | MS | WTR | 

-------- 4-------4------4------4------4------4+----- 4+ 
N |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i | 
UA:LO:L | i | i i | i |, 2 Ve 
UA:P:L | [10] | å | [19] | i | å |i 
UA:LO:R | i a i |a |i Lä 
UA:P:R  |UA:LO:R| i [PA:F:R| i ME | i | 
PF:W:L [11] [12] |PA:F:R| i i Å | 
PF:W:R Fe OA i | i | [14] 
PA:F:L |UA:LO:R| i | i | i es | i | 
PA:M:L |UA:LO:R|UA:P:R|PA:F:R| [13] | i E | 
PA:F:R |UA:LO:R| i | i Er NS | i | 
PA:M:R |UA:LO:R|UA:P:R|PA:F:R| [13] | i | i | 
WTR UA RUE PA:F:R|PF:W:R|PA:M:R| i 
DNR Du UA:P:R|PA:F:R|PF:W:R|PA:M:R| i 

The following are the footnotes for the table: 
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the current state (UA:LO:R) 
the current state (UA:LO:R) 
the current state (UA:P:R) 
the current state (PA:F:R) 


being cleared is SF-P, tran 


ignore the clear. 
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MS | WTRExp 
c +-—-—-—-—-—-—- 
A:M:L| i 
i -i 
ï (a 
i |i 
i å 
i | i 
i | å 
i I es. 
i rå 
i (az 
A:M:L| i 
A:M:L| [9] 
x i 
DNR | NR 
A +-—-—-—-—-—- 
i | å 
zl | å 
i | å 
i | [16] 
i | [16] 
i a 
[15] | N 
i ie: 
i a 
DNR | [17] 
DNR | N 
i [18] 
i i 
SF (0,0). 
SF (1,0). 
SF (1,0). 
SF (1,1). 
If it's 
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[6] 


[7] 


[8] 
[9] 
[10] 
[11] 
[12] 
[13] 


[14] 


[15] 


[16] 


[17] 


[18] 


[19] 


MPLS-TP LP October 2011 


Remain in current state (UA:x:R), if the SFc corresponds to a 
previous SF, then begin transmitting NR(0,0). 


If domain configured for revertive behavior transition to WTR, 
else transition to DNR. 


Remain in PA:F:R and transmit NR(0,1). 


Remain in WTR, send NR(0,1). 


Transition 


Transition 


Transition 


Transition 


Transition 
message. 


Transition 
message. 


to UA:LO:R continue sending SF(0,0). 
to UA:LO:R and send SF(1,0). 

to UA and send SF(1,0). 

to PF:W:R and send NR(0,1). 


to WTR state and continue to send the current 


to DNR state and continue to send the current 


If the local input is SF-P, then transition to UA:P:L. If the 
local input is SF-W, then transition to PF:W:L. Else, 


transition 


to N state and continue to send the current message. 


If the local input is SF-W, then transition to PF:W:L. Else, 


transition 


to N state and continue to send the current message. 


If the receiving LER's WIR timer is running, maintain current 


state and message. If the WIR timer is stopped, transition to 
N. 
Transition to PA:F:R and send SF (0,1). 
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Appendix B. Exercising the Protection Domain 


There is a requirement in [RFC5654] (number 84) that discusses a 
requirement to verify that the protection path is viable. While the 
PSC protocol does not define a specific operation for this 
functionality, it is possible to perform this operation by combining 
operations of the PSC and other OAM functionalities. One such 
possible combination would be to issue a Lockout of protection 
operation and then use the OAM function for diagnostic testing of the 
protection path. Similarly, to test the paths when the working path 
is not active would involve performing a Forced Switch to protection 
and then perform the diagnostic function on either the working or 
protection path. 
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